home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
kermit.columbia.edu
/
kermit.columbia.edu.tar
/
kermit.columbia.edu
/
newsgroups
/
misc.19990422-19990725
/
000121_news@watsun.cc.columbia.edu _Mon May 31 18:53:38 1999.msg
< prev
next >
Wrap
Internet Message Format
|
1999-07-23
|
5KB
Return-Path: <news@watsun.cc.columbia.edu>
Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.59.30])
by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id SAA02607
for <kermit.misc@watsun.cc.columbia.edu>; Mon, 31 May 1999 18:53:38 -0400 (EDT)
Received: (from news@localhost)
by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id SAA17445
for kermit.misc@watsun.cc.columbia.edu; Mon, 31 May 1999 18:39:26 -0400 (EDT)
X-Authentication-Warning: newsmaster.cc.columbia.edu: news set sender to <news> using -f
From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
Subject: Re: timing problems
Date: 31 May 1999 22:39:26 GMT
Organization: Columbia University
Message-ID: <7iv32u$h12$1@newsmaster.cc.columbia.edu>
To: kermit.misc@watsun.cc.columbia.edu
In article <37530A82.194A@ix.netcom.com>,
Joe H. Gallagher <dtrwiz@ix.netcom.com> wrote:
: Following is two examples of K95 script code which work on a
: slower processor, but fail to work on a faster processor.
:
: Example #1
:
: Sending three <CR> to wake up a VAX thru a DECserver 700 to
: start the login process.
:
: The following code worked on a 175 Megahertz processor, but would
: NOT work on a faster processor.
: . . .
: :LOOP1
: clear
: message {Requesting username prompt...}
: output \13\13\13
: input 2 Username:
: if success goto HAVEUSERNAME
: goto LOOP1
: :HAVEUSERNAME
: message {Logging in . . . }
: output \%a\13 ; send username
: output \%p\13 ; send password
:
: The faster processor required code like:
: . . .
: :LOOP1
: clear
: message {Requesting username prompt...}
: output \13
: message {Synchronizing .}
: output \13
: message {Synchronizing . .}
: output \13
: message {Synchrohizing . . .}
: input 2 Username:
: if success goto HAVEUSERNAME
: goto LOOP1
: :HAVEUSERNAME
: message {Logging in . . . }
: output \%a\13 ; send username
: output \%p\13 ; send password
:
I think you answered your own question. The faster PC sends the three
carriage returns faster than the DECserver can handle them. It's always
better to build lots of robustness into a script. You might even want to
put "msleep 200" or somesuch between the OUTPUTs to ensure a minimum
interval between the carriage returns.
: Example 2.
:
: A DATATRIEVE procedure VALIDATION is started on the VAX. The
: KERMIT script is to wait until the procedure responds with a "Done".
: The following code worked on a 175 Megahertz processor, but would
: not work on a faster processor.
:
: . . .
: message {Analyzing claims . . .}
: clear
: output dtr execute validation\13
: set count 180 ; 180 * 5 second / 60 second/min = 15 minutes
: :Y1
: message {Synchronizing with host during validation . . .}
: input 5 Done
: if success goto CONT3
: reinput 0 CARRIER
: if success goto ENDVAL
: if count goto Y1
: :ENDVAL
: fatalerror {Verification never completed.}
: :CONT3
: . . .
:
: On a faster processor, the script file would "hang" on the line
: "input 5 Done".
:
Most likely because "output dtr execute validation\13" sent characters too
fast for the VAX, so it didn't understand the command, and therefore never
said "Done".
Both cases suggest a lack of adequate flow control on the VAX and/or DECserver
end of the connection. Of course you can add pauses and (m)sleeps, or for
that matter "set output pacing" commands to your script to compensate, but
it's better to just fix the flow control.
: Questions:
:
: 1. How does one write K95 scripts which are independent of
: the speed of PC?
:
By having an effective form of flow control at every juncture along the
connection, or, when that is not possible, by inserting pauses and/or using
"set output pacing" to control the rate at which characters are sent -- that
is, to make it indpendent of the processor speed.
: 2. Which script commands are most likely to encounter timing or
: processor speed problems?
:
Any command that sends a block of characters. But again, the processor speed
is not the real issue.
: 3. Are these kinds of problems unique to the hardware I am using?
: to K95? or to KERMIT scripts in general?
:
No, they are symptomatic of a connection that lacks adequate flow control.
Look first at the connection between the DECserver and the modem. Does your
DECserver use MMJ connectors? In that case, it does not have a full
complement of modem-signal wires, and the port must be configured to sacrifice
certain functions -- e.g. you can have hardware flow control, or you can have
automatic hangup detection, but you can't have both. If the ports are
configured for the latter, then you must enable *local* Xon/Xoff flow control
between the modem and the DECserver.
You probably would not be seeing these problems with a terminal server that
uses 9-pin or 25-pin D connectors.
See Appendix II of "Using C-Kermit" for an overview of these issues. See the
VMS C-Kermit installation notes (ckvins.doc) for a discussion of DECserver
configuration.
- Frank